test: Avoid hang in big segment status polling specs - #440

Root cause

BigSegmentStoreManager.new starts its status poll worker immediately (start_delay of 0), and BigSegmentStoreStatusProviderImpl#update_status only notifies observers when the status differs from the previous one. Both status polling examples constructed the manager, then added an observer, then blocked on Queue#pop for the initial status. If the worker's first poll ran before add_observer, the initial status was already recorded, no notification was ever sent, and the unbounded Queue#pop blocked forever — taking the whole rspec process with it, so RuboCop and the gem build never ran and the job sat until it was cancelled at the 6 hour limit.

MRI generally loses that race (a newly spawned thread does not run until the main thread yields), which is why this only showed up on the JRuby job, where threads run truly concurrently.

Solution

The examples now read the initial status directly from status_provider.status and use a helper that waits, with a timeout, for the next status matching a predicate. That makes them independent of whether a status was queued before the observer was registered, and a broken expectation now fails instead of hanging.

The job timeout is defense in depth: any other future hang in tests, rubocop, or contract tests now fails the job in minutes.

Alternatives considered

Changing the manager to delay the first poll or to always notify on the first status would make the specs pass, but that changes SDK behavior to accommodate a test, and the current behavior (no notification unless the status changes) is intended.

Testing

Reproduced the hang locally on JRuby 9.4.15.0 (2 pinned cores), where the status polling group hung every attempt before the change and passed repeatedly after it. The full suite (bundle exec rspec spec --tag '~flaky') passes on JRuby with the persistent stores running.

Known remaining issue (not addressed here)

ld-eventsource connection threads can still outlive an example and call into an expired rspec double via StreamProcessor#log_connection_result, which prints an ExpiredTestDoubleError from a terminating thread. It is noisy but does not hang or fail the suite; worth a separate look.